Guided attachment of policies in a service registry environment

ABSTRACT

A method includes receiving a reference to a selected description document for policy attachment, the selected description document including at least one definition to describe a Web Service. The method includes locating a logical object of the selected description document that permit policy attachment. The method also includes receiving a reference to the logical object that is located for policy attachment. The method includes locating at least one policy that is operable to be associated with the logical object that is referenced, wherein the at least one policy defines a rule for the Web Service. The method includes receiving a reference for a selected policy from among the at least one policy. The method includes attaching the selected policy to the selected description document.

RELATED APPLICATIONS

This application claims the priority benefit of U.S. application Ser.No. 12/849,542 filed Aug. 3, 2010, entitled “Guided Attachment ofPolicies in a Service Registry Environment”, which claims prioritybenefit of European Patent Application No. 09167272.5 filed Aug. 5,2009, entitled “Guided Attachment of Policies in a Service RegistryEnvironment.”

BACKGROUND

Service oriented architecture (SOA) is a business-driven ITarchitectural approach that supports integrating the business as linked,repeatable business tasks, or services. The basic building block is aservice document that defines a service so that it can be managed withother services. A service document contains information about a serviceincluding the location of the service and details about the service andhow to access the service. Service documents are used by analysts,architects, and developers during a Development Phase of the SOA lifecycle to locate services to reuse and to evaluate the impact of changesto service configurations. Service documents are variously described asmetadata, objects, descriptions, entities and artifacts.

A service repository stores the service document and allows access tothe service document and thereby the corresponding service. A serviceregistry is an index of a subset of information about a service (forexample the location and name of service document) enabling thecorresponding service document to be located and accessed in arepository (or even the corresponding service located at the serviceprovider). An integrated service registry and repository allows aservice operation to use both the indexed service information in theregistry and the detailed service information in the repository. Anexample of an integrated service registry and repository is IBM®WebSphere® Registry and Repository (WSRR).

Such an integrated service registry and repository has advantages ofgreater business agility and resilience through reuse than separatesystems. Further advantages of looser coupling, greater flexibility,better interoperability, and better governance arise from theintegration. These advantages are addressed by separating servicedescriptions from their implementations, and using the servicedescriptions across the life cycle of the service. Standards-basedservice metadata artifacts, such as Web Service Definition Language(WSDL), extensible mark-up language (XML) schema, policy or ServiceComponent Architecture (SCA) documents, capture the technical details ofwhat a service can do, how it can be invoked, or what it expects otherservices to do. Semantic annotations and other metadata can beassociated with these artifacts to offer insight to potential users ofthe service on how and when it can be used, and what purposes it serves.

A policy is a rule that is applied to an object by an environment. Forinstance, access to an object can be controlled by applying a rule thatonly entities with a certain token can have access to the object. W3C(World Wide Web Consortium) is a community working together to developinteroperable internet technology.

WS-Policy is a W3C WS (Web Service) standard that is intended to providea means for specifying policies that need to be applied to Web Servicesand specifically service documents. The WS-Policy-Attach specification(also controlled by the W3C) specifies a standard means by which policyattachments can be defined to link a policy to a service objectreferenced in a service document. Service objects or logical objects arederived from documents (WSDL (Web Service Definition Language)documents; XSD (XML schema definition) documents; XML (extensiblemark-up language) documents, WS-Policy documents etc.) when they areloaded into the Service Registry environment. The WS-Policy-Attachspecification declares different means of specifying policy attachmentsthat link specific policies to target subjects: embedded policies inWSDL documents; embedded policy references in WSDL documents; embeddedpolicy references from policyURI (Universal Resource Indicator)attributes in WSDL documents; embedded policies in external policyattachment files; and embedded policy references in external policyattachment files.

A Policy can be a generic policy as defined in the WS-Policy Frameworkor it can be a domain specific policy as defined in a policy domain. Ifa policy is domain specific then it will specify the WSDL Elements towhich it can be attached.

One problem when specifying policy attachments is the complexity of thesemantics required to correctly specify the attachment. For instance anidentifier for a policy can comprise two or more parts: a namespace; aWSDL element type; and actual element name. Another problem users faceis an array of choices when it comes to attaching policies to subjectsbut no easy way of identifying the right subjects to attach the policiestoo. A further problem for a user that has found an element there is noeasy way to see which policies can be attached to it. All these problemscan quickly lead to the creation of either invalid or incorrect policyattachment documents.

SUMMARY

In some example embodiments, a method includes receiving a reference toa selected description document for policy attachment, the selecteddescription document including at least one definition to describe a WebService. The method includes locating a logical object of the selecteddescription document that permits policy attachment. The method alsoincludes receiving a reference to the logical object that is located forpolicy attachment. The method includes locating at least one policy thatis operable to be associated with the logical object that is referenced,wherein the at least one policy defines a rule for the Web Service. Themethod includes receiving a reference for a selected policy from amongthe at least one policy. The method includes attaching the selectedpolicy to the selected description document.

BRIEF DESCRIPTION OF THE DRAWINGS

The present embodiments may be better understood, and numerous objects,features, and advantages made apparent to those skilled in the art byreferencing the accompanying drawings.

Embodiments are now be described, by means of example only, withreference to the accompanying drawings in which:

FIG. 1 is a schematic of service document phases in a service registryand repository, according to some example embodiments.

FIG. 2 is a schematic of an architecture having a service registry andrepository, according to some example embodiments.

FIG. 3 is a schematic of a service registry and repository informationarchitecture, according to some example embodiments.

FIG. 4 is a schematic of a system having registry that includes a policyattachment tool, according to some example embodiments.

FIG. 5 is a flowchart for attaching a policy to an object of adescription document, according to some example embodiments.

FIG. 6 shows an example WebSphere Service Registry and Repositoryscreenshot of the Policy Attachment tool before an attachment is made,according to some example embodiments.

FIG. 7 shows the screenshot of FIG. 6 after the attachment is made,according to some example embodiments.

DESCRIPTION OF EMBODIMENT(S)

Some example embodiments include a service registry and repository forservice documents based on IBM WebSphere Service Registry andRepository. Such service documents include traditional internet servicesthat use a range of protocols and are implemented according to a varietyof programming models.

FIG. 1 is a schematic of service document phases in a service registryand repository, according to some example embodiments. In particular,FIG. 1 illustrates service life cycle phases of the services stored asdocuments in the service registry and repository comprising: ServiceDevelopment; Change and Release Management; and Runtime Integration andOperation. As the integration point for service metadata, the serviceregistry and repository establishes a central point for finding andmanaging service metadata acquired from a number of sources, includingservice application deployments and other service metadata and endpointregistries and repositories. The service registry and repository iswhere service metadata that is scattered across an enterprise is broughttogether to provide a single, comprehensive description of a service.Once this happens, visibility is controlled, versions are managed,proposed changes are analyzed and communicated, usage is monitored andother parts of the service architecture can access service metadata withthe confidence that they have found the copy of record.

Software Architecture

The service registry and repository, in accordance with some exampleembodiments, is a Java™ 2 Platform Enterprise Edition (J2EE) applicationthat runs on a WebSphere Application Server 8 and uses a triplestoredatabase 9 as a backing store to persist the service metadata. Theservice registry and repository takes advantage of the role-based accesscontrol so that role-based views and access control can be turned onwhen the service registry and repository is deployed as anenterprise-wide application.

FIG. 2 is a schematic of an architecture having a service registry andrepository, according to some example embodiments. In particular in FIG.2, top level components of the service registry and repository 10comprise: a registry 12; repository 15; a governance 20; anadministration interface 26; a user interface 28; a programminginterface 30.

The registry 12 offers both registry function and repository functionfor service metadata. The repository function allows users to store,manage and query service metadata artifacts holding servicedescriptions. It not only takes good care of the documents containingservice metadata by reliable persistence of the data, but it alsoprovides a fine-grained representation of the content of those documents(for example, ports and portTypes in some service documents). Theregistry function makes provision for decorating registered servicedeclarations and elements of the derived content models withuser-defined properties, relationships, and classifiers. The registry 12provides a policy attachment tool 14. In use client browser 40 displayspolicy user interface document 42 for editing by user 44.

In some example embodiments, repository 15 stores all artifactsincluding policy documents 414 and domain policy definitions 416.

Classification component 22 allows service descriptions and parts ofservice definitions to be annotated with corporate vocabulary and tocapture the governance state. Service classification systems arecaptured in web ontology language (OWL) documents that are loaded intothe Service Registry and Repository using the administrative interface.Service registry and repository entities can be classified with valuesfrom these classification systems, to allow classification-based queriesto be performed, and to allow access restrictions based onclassification.

Access controller 24 supports a fine-grained access control model thatallows for the definition of which user roles can perform specific typesof actions on corresponding artifacts. Visibility of services can berestricted by business area and user roles can be restricted fromtransitioning services to certain life cycle states. This is in additionto the role-based access control provided by the service registry andrepository.

Administration interface 26 supports the import and export of repositorycontent for exchange with other repositories and provide an API forconfiguration and basic administration. These support interactions withthe Access Controller and with the Classifier.

User interface 28 comprises a web interface and an Eclipse* plug-ininterface to enable interaction with service registry and repository. Aservlet based web user interface (UI) supports is the main way for usersrepresenting different roles to interact with the service registry andrepository. The web interface can support all user roles, offeringlookup, browse, retrieve, publish, and annotate capabilities, as well asgovernance activities, such as import/export and impact analysis. Asubset of this user interface is offered as an Eclipse plug-in to meetdeveloper needs and analyst users needs that use Eclipse-based tooling.The Eclipse plug-in is used primarily for lookup, browse, retrieve andpublish capabilities. The Web-based user interface can also be used forperforming service metadata management and governance.

Programming interface 30 uses Java and SOAP (Service OrientedArchitecture Protocol) APIs to interact programmatically with registryand repository core 12. These APIs provide basic create, retrieve,update and delete (CRUD) operations, governance operations, and aflexible query capability. The SOAP API is used to communicate contentusing XML data structures. The Java API is used to communicate contentusing service data object (SDO) graphs. Using either the user interface30 or the programming interface 28 documents and concepts managed byWSRR can be created, retrieved, updated and deleted. However, logicalentities in the logical model cannot be modified and these can only bechanged by updating a document that contains the logical entity.Concepts can be created, retrieved and deleted.

The service registry and repository of some example embodiments supportstwo application programming interfaces (APIs) that can be used tointeract with the registry 12; repository 15; the governance component20 and the administration interface 26: a Java-based API and aSOAP-based API respectively. Both APIs support publishing (creating andupdating) service metadata artifacts and metadata associated with thoseartifacts, retrieving service metadata artifacts, deleting metadata, andquerying the content of the registry and repository. The programmingAPIs use Service Data Objects (SDO) to capture the data graphs inherentin the content model, allowing access to physical documents, logicalparts of the physical documents, and concepts. The SOA API uses XMLdocuments to similarly represent Service Data Objects to communicatecontent structures in both the physical and logical model.

Information Architecture

FIG. 3 is a schematic of a service registry and repository informationarchitecture, according to some example embodiments. In FIG. 3, theinformation architecture 300, in accordance with some exampleembodiments, is described. Broadly, information architecture 300 hasentities representing service description entities 302 and servicedescription metadata 304. In some example embodiments, all artifactshave an assigned URI, a name and a description. Examples of each type ofartifact are shown in FIG. 3 but are not necessarily referred to in thedescription.

Service Description Entities 302 comprise physical documents 306;logical derivations 308 and concepts 310. Physical Documents 306 are XMLdocuments that are known as service metadata artifacts. Logicalderivations 308 are the finer-grained pieces of content that result whensome types of physical document are shredded as they are loaded intoRegistry and Repository. Concepts 310 are generic entities that areusually typed, and represent anything that is not represented by adocument in Registry and Repository. All three types of servicedescription entities can be used in queries, have service annotationsapplied, and have relationships established from and to them.

The most elemental building blocks for the WSRR are the physicaldocuments 306 such as XSD, WSDL or WS-Policy documents. In addition anyXML service metadata artifact type or binary document can be stored inWSRR and receive the benefits of broader visibility, reuse, management,and governance. The coarse-grained model made up from registry objectsthat represents those documents is referred to as the physical model.Documents are versionable objects in the WSRR content model, which meansthat in addition to a URI, name, and description, they also can have aversion property.

For some of the physical document types, WSRR derives logical objectsand stores them in logical derivations 308. For instance, WSRR can“shred” a document upon receipt into a set of logical objects to enableusers to explore WSRR content beyond the boundaries of the files stored.In some example embodiments, logical objects are not versionable. Forsome physical document types, WSRR defines predefined properties anddetects relationships to other physical documents. An XSD document, forexample, has a target Namespace property and the relationships withother imported XSD documents, other redefined XSD documents and otherincluded XSD documents. When an entry for a certain physical document iscreated in WSRR, it is inspected for relationships to other artifacts.If not already represented in WSRR, a related artifact is also added,and in either case the relationship between the artifacts is recorded.

The set of logical derivations comprises the logical model of WSRR. Thelogical model has entities such as portType, port, and message relatedto WSDL files, and complexType or simpleType related to XSD documents.Elements of the logical model have properties and relationshipsreflecting a subset of their characteristics as defined in theunderlying document. For example, a WSDLService element has a namespaceproperty and a relationship to the ports it contains. It is important tonote that all individual results of document shredding are aggregatedinto one logical model that represents not only the content ofindividual documents, but also relationships between content indifferent documents.

WSRR stores other types of service metadata using the XML Document, ageneric document type. Documents of type XMLDocument are not decomposedinto the logical model.

WSRR uses a concept to represent anything that does not have a physicaldocument. Concepts 310 are used to represent a reference to content insome other metadata repository, such as a portlet in a portlet catalogueor an asset in an asset repository. It can also be used to groupphysical artifacts together to govern them as a unit; for example,concepts can be versioned.

In addition to content directly related to entities 302, WSRR supports anumber of metadata types that are used to describe entities 302. Thesemetadata types are referred to as service description metadata 304. WSRRsupports three types of service semantic metadata types: properties 312;relationships 314; and classifications 316. All three types describephysical model entities, logical model entities, and/or concepts. Forexample, service description metadata can be used to associate aproperty “businessValue” with a physical model entity representing aWSDL file. It might also be used to define a new relationship“makesUseOf” between an entity in the logical model representing a“portType” and an entity in the physical model representing an XMLdocument. Furthermore one could create a classification of“importantThings” and associate it with a “port” entity in the logicalmodel and with an entity in the physical model representing a “Policy”document. This enables semantic queries to target individual elements ofthe service metadata, and meaningful dependency analyses to take placeprior to making changes.

Properties 312 are simple name/value pairs that are associated with anyof the Service Description Entities 302. Some properties are assigned bythe system, such as the unique id, the owner, and the last time theservice entity was changed. These system-assigned properties cannot bechanged. Others are derived through the “shredding” of a key-typeservice description document into its logical model. Properties of thistype include name and namespace. Sometimes these system-assigned valuesare allowed to be changed and properties can be created. Such auser-defined property can be used as a simple, unstructured and untypedextension mechanism. Properties 312 can be used in queries, and can beused to establish fine-grained access control.

Relationships 314 tie together one source service description entity toone or more target service description entities. Every relationship canbe given a name and a source is only allowed to have a singlerelationship with a given name. Some relationships are assigned by WSRRduring the “shredding” of key types of documents. The relationshipestablished between XSD documents based on the importing of one into theother is one such system-assigned relationship. Relationships can alsobe user defined. For example, a user can: relate a concept thatrepresents an external object to a service using a user definedrelationship; relate all of the service description documents that willbe governed as a unit to a governable entity; and/or relate a monitoringpolicy to a service endpoint.

A user can load classification 316 into registry where it can then beused to apply semantic meaning to service description entities 302.Classification systems are documents encoded using the Web OntologyLanguage (OWL). The registry represents OWL Classes as classifiers andinterprets the subTypeOf relationship between those Classes asestablishing a classifier hierarchy. Other OWL concepts such as data orrelationship representing properties or other built-in OWL relationshipsare ignored. A classification system is imported into the registry as awhole and updates are made by importing a modified version of theontology. Any class in the underlying ontology can be used as aclassification; the same classification can be used to classify multipleentities and an entity can be associated with multiple classifications.

Policy Attachment Tool

FIG. 4 is a schematic of a system having registry that includes a policyattachment tool, according to some example embodiments. In FIG. 4, thereis shown a policy attachment tool 14 comprising: document referencereceiver 402; object list builder 404; object user interface builder406; attach policy receiver 408; policy locator 410; policy interfacebuilder 412; policy receiver 414; policy attacher 416; and policyattachment completer 418.

Document reference receiver 402 acquires a WSDL document referenceselected by the user. A user selects a WSDL document for a policyattachment by sending an http request to the policy attachment tool 14containing a reference to the WSDL document.

Object list builder 404 locates all the logical objects of the selectedWSDL document as defined in the repository and builds a list from them.Each of the logical objects represents an element in the selected WSDLdocument.

Object User interface builder 406 presents the located logical objectsto the user as a marked up list along with hypertext markup options toattach policies. On selection of a hypertext markup option an httprequest is made to the editing tool requesting that a particular objecthave a policy attached to it.

Attach policy receiver 408 listens for user selection of one or morelogical objects with a view of attaching a policy. In this embodiment,the attach policy receiver receives an http request for attachment of apolicy to a selected object.

Policy locator 410 searches all policies (that is logical objects in therepository that define policies) in order to locate policies that may beassociated with the selected logical object. Only some policies aresuitable for attachment to some types of logical object and a smallersubset of policies depend on properties of a logical object. The typeand properties of the object are checked against the available policies.

Policy interface builder 412 presents a list of the suitable policies tothe user. In some example embodiments, a search bar with type aheadsearch is used but in other embodiments a drop down list is used.

Policy receiver 414 listens for a user selection of a policy from thelist of located policies.

Policy attacher 416 attaches the selected policy to the selected objectby creating a policy attachment document that references both the policydocument and the logical object to which it is associated.

Policy attachment completer 418 listens for user input as to whetherpolicy is completed. In some example embodiments, the policy interfacebuilder includes a button marked “finish” that sends a finish messageback to the tool. When this finish message is received then the sessionis ended.

Policy Attaching

FIG. 5 is a flowchart for attaching a policy to an object of adescription document, according to some example embodiments. In FIG. 5,there is shown a method 500 of the policy attachment tool 14 accordingto some example embodiments.

At block 502, a user selects a WSDL document for a policy attachment bysending an HTTP request to the policy attachment tool 14 containing areference to the WSDL document. In another embodiment a page ofdocuments might be presented to a user so that a particular documentmight be selected.

At block 504, the policy attachment tool locates all the logical objectsof the selected WSDL document as defined in the repository. If necessarythe document is shredded to create logical objects in the repository.Each of the logical objects represents an element in the selected WSDLdocument. The located logical objects are presented to the user as alist.

At block 506, the user selects one or more logical objects with a viewof attaching a policy.

At block 508, the tool searches all policies (that is logical objects inthe repository that define policies) in order to locate policies thatmay be associated with the selected logical object. Only some policiesare suitable for attachment to some types of logical object and asmaller subset of policies depend on properties of a logical object. Thetype and properties of the object are checked against the availablepolicies. A list of the suitable policies is created and presented tothe user.

At block 510, the user selects a policy from the list of locatedpolicies. In some example embodiments, a search bar with type aheadsearch is used but in other embodiments a drop down list is used.

At block 512, the tool attaches the policy to the document. In someexample embodiments, the tool creates a policy attachment document thatreferences the policy document and the logical object to which it isassociated. Such an operation allows both the WSDL document and thePolicy document to remain unchanged.

At block 514, the tool receives input from the user as to whetheranother policy is to be attached to an object and returns to block 506if this is true. If no more attachments are to be made then the methodends.

EXAMPLE

The policy editing tool, in accordance with some example embodiments,allows the user to select the WDSL element (subject) for attaching apolicy to, and then to search the registry for a policy that to attachto the subject. Only policies that are defined as being allowed to beattached to the specific type of WSDL element will be presented to theuser.

To illustrate, FIG. 6 shows an example WebSphere Service Registry andRepository screenshot of the Policy Attachment tool before an attachmentis made, according to some example embodiments. The screen capture ofFIG. 6 shows a source WSDL document that contains elements to whichusers want to attach policies. For each element there is an ‘AttachPolicy’ link that when clicked, brings up the “Add Policy Attachment”window section 600. In this example, the user has selected 601 thedocument element with Binding name=“StockQuoteBinding”. In the “AddPolicy Attachment” window 600 the user has typed the first few lettersof the policy name “Del” and a policy “DeletionsPolicy_eap_policy” isselected from a drop down list of policies located by the policy editingtool. In this example, a “Policy Attachment” document is created joinsthe policy to the object. An example of a Policy Attachment document is:

<wsp:Policy> <wsp:PolicyAttachment> <wsp:AppliesTo><wsrr:PolicySubjectQuerywsrr:xpath=“//WSDLPort[@bsrURI=‘a76022a7-8c73-4322.8dd5.64c88364d5fb’]”/> </wsp:AppliesTo> <wsp:PolicyReferenceURI=“DeletionsPolicy_eap_policy” /> </wsp:PolicyAttachment </wsp:Policy>

The meaning of this policy attachment document is that the policyidentified by the <wsp:PolicyReference> will be attached to the WSDLelement identified by the XPath expression in <wsrr:PolicySubjectQuery>.FIG. 7 shows the screenshot of FIG. 6 after the attachment is made,according to some example embodiments. The screen capture of FIG. 7shows the list of documents elements with a Policy Attachment Document701 attached to the previously selected element. A Policy Propertieswindow 703 is displayed when the Policy Attachment document 701 isselected. Once the user has finished attaching policies to the WSDLelements they may click on “Finish”.

Other Embodiments

It will be clear to one of ordinary skill in the art that all or part ofthe method of some example embodiments may suitably and usefully beembodied in a logic apparatus, or a plurality of logic apparatus,comprising logic elements arranged to perform the operations of themethod and that such logic elements may comprise hardware components,firmware components or a combination thereof.

It will be equally clear to one of skill in the art that all or part ofa logic arrangement according to some example embodiments can suitablybe embodied in a logic apparatus comprising logic elements to performthe operations of the method, and that such logic elements may comprisecomponents such as logic gates in, for example a programmable logicarray or application-specific integrated circuit. Such a logicarrangement may further be embodied in enabling elements for temporarilyor permanently establishing logic structures in such an array or circuitusing, for example, a virtual hardware descriptor language, which may bestored and transmitted using fixed or transmittable carrier media.

It will be appreciated that the method and arrangement described abovemay also suitably be carried out fully or partially in software runningon one or more processors (not shown in the figures), and that thesoftware may be provided in the form of one or more computer programelements carried on any suitable data-carrier (also not shown in thefigures) such as a magnetic or optical disk or the like. Channels forthe transmission of data may likewise comprise storage media of alldescriptions as well as signal-carrying media, such as wired or wirelesssignal-carrying media.

Some example embodiments can further suitably be embodied as a computerprogram product for use with a computer system. Such an implementationcan comprise a series of computer-readable instructions either fixed ona tangible medium, such as a computer readable medium, for example,diskette, CD-ROM, ROM, or hard disk, or transmittable to a computersystem, using a modem or other interface device, over either a tangiblemedium, including but not limited to optical or analogue communicationslines, or intangibly using wireless techniques, including but notlimited to microwave, infrared or other transmission techniques. Theseries of computer readable instructions embodies all or part of thefunctionality previously described herein.

Those skilled in the art will appreciate that such computer readableinstructions can be written in a number of programming languages for usewith many computer architectures or operating systems. Further, suchinstructions may be stored using any memory technology, present orfuture, including but not limited to, semiconductor, magnetic, oroptical, or transmitted using any communications technology, present orfuture, including but not limited to optical, infrared, or microwave. Itis contemplated that such a computer program product may be distributedas a removable medium with accompanying printed or electronicdocumentation, for example, shrink-wrapped software, pre-loaded with acomputer system, for example, on a system ROM or fixed disk, ordistributed from a server or electronic bulletin board over a network,for example, the Internet or World Wide Web

Some example embodiments can be realized in the form of a computerimplemented method of deploying a service comprising steps of deployingcomputer program code operable to, when deployed into a computerinfrastructure and executed thereon, cause the computer system toperform the operations of the method.

Some example embodiments can be realized in the form of a data carrierhaving functional data thereon, said functional data comprisingfunctional computer data structures to, when loaded into a computersystem and operated upon thereby, enable said computer system to performthe operations of the method.

It will be clear to one skilled in the art that many improvements andmodifications can be made to the foregoing exemplary embodiment withoutdeparting from the scope of embodiments described herein.

Abbreviations API Application Programming Interface J2EE Java ™ 2Platform Enterprise Edition OWL Web Ontology Language SCA ServiceComponent Architecture SDO Service Data Object SOA Service OrientedArchitecture SOAP Service Oriented Architecture Protocol URI UniformResource Indicator W3C (World Wide Web Consortium) WS Web Service WSDLWeb Service Definition Language WSRR IBM WebSphere Registry andRepository XML extensible mark-up language XSD XML Schema Definition

NOTICES

IBM and WebSphere are registered trademarks or trademarks ofInternational Business Machines Corporation in the United States and/ orother countries. Java and all Java-based trademarks are trademarks ofSun Microsystems, Inc. in the United States, other countries, or both.Eclipse is a trademark of Eclipse Foundation, Inc.

1. A method comprising: receiving a reference to a selected descriptiondocument for policy attachment, the selected description documentincluding at least one definition to describe a Web Service; locating alogical object of the selected description document that permits policyattachment; receiving a reference to the logical object that is locatedfor policy attachment; locating at least one policy that is operable tobe associated with the logical object that is referenced, wherein the atleast one policy defines a rule for the Web Service; receiving areference for a selected policy from among the at least one policy; andattaching the selected policy to the selected description document. 2.The method of claim 1, wherein locating the at least one policy that isoperable to be associated with the logical object comprises checking atype and properties of the logical object against an object type andobject properties that the at least one policy accepts.
 3. The method ofclaim 1, wherein locating the at least one policy that is operable to beassociated with the logical object comprises checking a type of thelogical object against an object type that the at least one policyaccepts.
 4. The method of claim 1, wherein locating the at least onepolicy that is operable to be associated with the logical objectcomprises checking properties of the logical object against objectproperties that the at least one policy accepts.
 5. The method of claim1, wherein the selected description document comprises a Web ServicesDefinition Language document.
 6. The method of claim 1, whereinattaching the selected policy to the selected description documentcomprises creating a policy attachment document that references theselected policy and the logical object.
 7. The method of claim 6,wherein the selected description document and the policy attachmentdocument are stored in a service registry and repository.
 8. The methodof claim 1, wherein the selected policy comprises a domain specificpolicy.